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ABSTRACT 

The  Naval  Surface  Warfare  Center,  Panama  City  Division  (NSWC  PCD)  designed  and  implemented  a 
new  tool,  The  Rapid  Mine  Simulation  System  Enterprise  Architecture  (RMSSEA),  to  support  existing  na¬ 
val  mine  warfare  simulations  and  to  provide  enhanced  future  mine  warfare  capabilities.  RMSSEA  sup¬ 
ports  existing  physics-based  models  of  Navy  assets  and  threats  in  order  to  provide  ship  susceptibility  and 
sweep  effectiveness  measures.  The  tool  expands  support  for  modeling  of  future  systems,  including  ma¬ 
neuverable  surface  and  underwater  unmanned  systems.  Additionally,  RMSSEA  allows  for  simulations  of 
distributed  sensor  and  mobile  warhead  devices.  The  tool  incorporates  improved  automation  and  visuali¬ 
zation,  which  reduces  simulation  setup  time  and  supports  increased  focus  on  results  analysis. 

1  INTRODUCTION 

The  Total  Mine  Simulation  System  (TMSS)  is  a  simulation  utilized  by  a  number  of  countries  to  simulate 
one-on-one  naval  mine  warfare  scenarios.  The  US  Navy  uses  TMSS  for  applications  including  operation¬ 
al  sweep  systems  effectiveness,  operational  surface  ship  susceptibility,  sweep  system  design  tradeoff  stu¬ 
dies,  ship  (and  submarine)  silencing  system  tradeoff  studies,  and  ship  live  fire  with  Follow-on  Test  and 
Evaluation  (FOT&E).  Though  widely  recognized  as  an  important  and  powerful  naval  mine  simulation 
tool,  TMSS  has  displayed  a  number  of  shortcomings  in  recent  years  which  hinder  support  for  emerging 
and  future  modeling  requirements.  These  shortcomings  include  lack  of  modem  software  development 
practices  resulting  in  a  system  which  is  difficult  to  upgrade  and  maintain.  This  problem  is  partly  due  to 
the  design  limitation  of  one-on-one  simulations  with  straight  line  target  motion. 

TMSS  shortcomings  led  to  the  recognition  of  the  need  for  a  modernized  simulation  capability.  A  new 
simulation,  the  Rapid  Mine  Simulation  System  Enterprise  Architecture  (RMSSEA),  designed  and  imple¬ 
mented  by  Naval  Surface  Warfare  Center  Panama  City  Division  (NSWC  PCD)  will  eventually  replace  the 
aging  TMSS,  providing  increased  capabilities,  speed,  ease  of  use  and  maintenance. 

1.1  Purpose 

This  paper  will  provide  a  description  of  the  newly  developed  simulation  RMSSEA.  At  a  high  level,  the 
simulation  design  and  implementation  will  be  discussed.  Additionally,  we  will  examine  how  RMSSEA 
overcomes  the  limitations  of  TMSS.  Capabilities,  such  as  simulation  domain  and  entity  types  pertinent  to 
naval  mine  warfare  and  analysis  reporting,  both  initial  and  envisioned,  will  also  be  analyzed.  Finally,  a 
description  of  the  simulation  problem  space  will  be  described  to  illustrate  the  simulation  system’s  usage. 
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1.2  Scope 

While  this  paper  will  provide  a  high  level  overview  of  RMS  SEA  design  and  usage,  it  is  not  intended  to  be 
highly  detailed.  RMSSEA  is  a  large  and  complicated  system  which  cannot  be  fully  detailed  in  a  single 
document.  Detailed  software  design  is  beyond  the  scope  of  this  document,  as  are  any  of  the  model  details 
and  equations  upon  which  the  simulation  is  based. 

1.3  History 

The  Total  Mine  Simulation  System  (TMSS)  has  been  in  use  by  the  US  Navy  since  the  1980s.  Originally 
developed  as  an  in-house  tool  for  the  UK’s  Admiralty  Research  Establishment  (ARE),  TMSS  has  now 
been  installed  in  weapons  research  establishments  around  the  world.  TMSS  consists  of  a  suite  of  simula¬ 
tion  and  assessment  software  providing  a  framework  within  which  the  interaction  of  signatures,  sensors, 
and  mine  algorithms  may  be  rigorously  investigated  and  evaluated.  Input  may  be  in  the  form  of  real  ship 
data  or  previously  calculated  coefficients  for  use  by  complementary  environmental  models  with  TMSS. 
Such  models  are  capable  of  predicting  a  ship’s  influence  at  points  other  than  the  original  recording  posi¬ 
tion.  Mines  are  defined  within  the  system  in  terms  of  the  characteristics  of  their  sensors  and  the  behavior 
of  their  algorithms.  TMSS  is  designed  so  that  users  may  design  and  implement  their  own  sensor  models 
and  mine  algorithms  within  the  framework  provided. 

Simulation  results  used  in  a  susceptibility  analysis  are  organized  and  presented  in  several  analytical 
outputs.  Typical  graphical  data  presentations  are  shown  in  Figure  1.  Figure  1  shows  the  onset  of  look  and 
actuation  contour.  The  format  shows  the  farthest  distance  abeam  as  a  function  of  water  depth  from  the 
watercraft  that  a  mine  will  fire  or  satisfy  the  particular  influence. 


FIRE  (MAGNETIC  SATISFIED) 


Figure  1:  Onset  of  Look  and  Actuation  Contour 


Naval  Surface  Warfare  Center  Panama  City  Division  (NSWC  PCD),  the  world  leader  in  Mine  War¬ 
fare,  Mine  Systems  &  Countermeasures,  has  used  TMSS  in  support  of  numerous  studies  as  well  as  direct- 
fleet  support  since  the  late  1980s.  All  models  currently  used  by  NSWC  PCD  in  the  TMSS  simulation  en- 
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vironment  have  been  entirely  developed  by  NSWC  PCD.  The  U.S.  configuration  of  TMSS  has  supported, 
among  many  other  traditional  programs,  several  mine  countermeasures  (MCM)  sweep  system  develop¬ 
ment  programs  as  well  as  the  DDG-51,  DDG-1000,  LPD-17,  and  other  surface  ship  platform  development 
programs. 

2  DESIGN 

2.1  Design  Methodology 

The  current  implementation  of  TMSS  is  written  in  standard  FORTRAN  and  executes  a  variety  of  models 
written  in  a  mix  of  the  FORTRAN  and  C  languages.  What  is  lacking  in  the  current  implementation  is 
many  of  the  state  of  the  art  software  development  practices  such  as  object  oriented  design  and  current- 
generation  developmental  tool  sets  that  provide  automated  reporting  and  code  generation.  These  limita¬ 
tions  leave  the  TMSS  code  difficult  to  upgrade  and  maintain.  To  overcome  the  shortcomings,  RMSSEA 
has  been  developed  with  object  oriented  design  and  analysis  techniques  from  the  beginning.  It  is  being 
implemented  under  the  Microsoft  .Net  framework,  allowing  for  utilization  of  the  integrated  Microsoft  tool 
sets.  This  also  provides  the  flexibility  of  integrating  legacy  C  and  FORTRAN  models  into  the  simulation. 
A  CASE  tool  is  also  utilized  for  code  generation  and  documentation. 

2.2  Distributed  Execution 

In  designing  the  RMSSEA  simulation  architecture,  the  primary  concerns  included  flexibility,  speed,  and 
ease  of  use.  As  part  of  the  effort  to  facilitate  these  concerns,  a  distributed  architecture  of  computers  is  uti¬ 
lized  to  process  simulation  scenarios  in  parallel.  As  seen  in  Figure  2,  the  simulation  maintains  a  central 
database  server  for  storage  of  all  scenario  initialization  and  data  collection  facilities.  There  is  also  a  cen¬ 
tralized  distribution  server  which  receives  simulation  requests  from  clients  and  distributes  the  tasking 
among  a  multitude  of  Execution  Nodes. 


■i 


1I«»I  Afc«Vt 


C.NiAnMbdi 


Figure  2:  Distributed  Architecture 

Graphical  user  interfaces  (GUIs)  exist  on  clients  for  easily  entering  data  into  the  simulation  and  pre¬ 
paring  for  execution.  Each  Execution  Node  is  capable  of  executing  a  series  of  simulation  scenarios,  as 
tasked  by  the  Distribution  Server,  and  storing  the  results  back  to  the  centralized  Database  Server.  It  is 
notable  from  the  figure  that  there  also  exist  stand  alone  installations  of  RMSSEA,  which  will  be  used  for 
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testing  and  developmental  purposes,  but  the  vision  is  to  have  executing  simulations  being  processed  on 
the  network. 

All  hardware  systems  within  the  simulation  are  standard  PC  architecture  executing  under  various 
Windows  based  environments.  The  distributed  environment  is  designed  for  flexibility  and  scalability  with 
centralized  data  storage. 

2.3  Model  Integration 

Though  much  of  the  simulation  utilizes  standard  components  such  as  GUIs  and  server  components,  a  rela¬ 
tively  unique  method  is  employed  to  facilitate  the  flexibility  of  the  system  on  the  back  end,  in  the  Execu¬ 
tion  Node  components.  Here,  rather  than  utilizing  a  standard  fixed  code  segment  for  each  model  in  the 
back  end,  the  Execution  Node  itself  provides  only  highly  generic  time  keeping  and  communications  facil¬ 
ities.  The  simulation  models,  such  as  acoustic  propagation,  ship  signatures,  motion,  etc...  are  all  main¬ 
tained  within  the  centralized  database  in  binary  format.  When  the  Execution  Node  is  tasked  with  a  portion 
of  a  scenario  to  execute,  it  synchronizes  the  binary  libraries  from  the  centralized  database  server  with  lo¬ 
cal  storage.  It  then  utilizes  the  locally  cached  libraries  to  perform  execution  as  required. 

This  unique  approach  provides  nearly  complete  independence  between  model  and  simulation  devel¬ 
opment.  Aside  from  implementing  a  few  simulation  specific  interfaces,  each  model  needs  to  know  rela¬ 
tively  little  about  the  simulation  itself  and  how  it  executes.  Each  model  uses  a  publish/subscribe  mechan¬ 
ism  where  it  independently  publishes  data  which  it  is  able  to  provide  and  similarly  subscribes  to  data 
which  it  wishes  to  consume.  Thus,  models  are  generally  free  from  knowledge  of  not  only  the  simulation 
but  other  models  as  well.  This  places  a  burden  on  developers  to  carefully  define  and  closely  adhere  to  in¬ 
terfaces  between  models  which  define  data  communication,  but  then  binds  models  to  those  interfaces,  ra¬ 
ther  than  to  the  models  on  the  other  side  of  the  communications  interface. 

3  CAPABILITIES 

The  simulation  environment  is  envisioned  as  a  standard  model  of  entities  moving  within  and  interacting 
through  a  defined  environment.  Entities  and  environments  are  composed  of,  and  defined  by,  meta  infor¬ 
mation  and  models  attached  to  the  entity  or  environment.  Each  entity  can  communicate  internally  be¬ 
tween  models  for  models  it  encapsulates,  or  externally  to  models  in  the  environment  or  other  entities,  in 
either  case  using  the  publish/subscribe  mechanism  implemented  by  the  system.  Entities  are  commonly  re¬ 
ferenced  as  Assets  for  Blue  Force  and  Weapons  for  Red  Force,  though  there  are  few  implementation  de¬ 
tails  separating  the  two  beyond  this  mental  mapping. 

Historically  in  TMSS,  assets  have  been  defined  by  a  simplified  constant-velocity  straight-line  motion 
model,  a  set  of  signatures  and  tightly  associated  propagation  models  that  define  the  asset.  Mines  have 
been  defined  by  a  set  of  sensors  that  receive  various  influences  and  an  algorithm  or  logic  model  that  rece¬ 
ives  sensor  outputs,  compares  threshold  levels,  implements  timing  requirements,  and  controls  the  actua¬ 
tion  decision.  The  interaction  space  of  the  simulation  is  attached  to  both  the  asset  motion  model  by  way  of 
starting  positions  -  initial  starting  position  and  closest  point  of  approach  -  as  well  as  the  simulation  defi¬ 
nition  itself  with  the  water  depth  and  therefore  depth  of  a  moored  or  bottom  influence  mine.  RMSSEA 
maintains  this  simplified  approach  for  one-on-one  simulations,  while  expanding  support  for  more  flexible 
definitions  of  the  interaction  space,  including  dynamic  motion  models  -  accelerating,  turning,  diving  - 
and  more  support  for  mine  types  beyond  the  simple  explode-in-place  bottom  influence  mine. 

3.1  Assets  and  Weapons 

Assets  in  RMSSEA  are  associated  with  meta  information  describing  the  basic  asset  physical  description, 
and  models  that  describe  relevant  parts  of  the  asset  within  the  context  of  the  simulation.  An  asset  includes 
an  internal  publish/subscribe  board  where  models  within  the  asset  may  communicate  without  that  infor¬ 
mation  being  visible  to  the  wider  simulation  environment.  An  asset  starting  position  is  defined  by  the  pa¬ 
rameters  of  an  initialization  model  appropriate  to  the  asset  type,  including  helicopters,  normal  Naval  sur- 
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face  ships  and  submarines,  unmanned  surface  and  underwater  vehicles,  and  towed  MCM  sweep  gear  with 
airborne,  surface,  or  underwater  tow  platforms.  Models  attached  to  the  entity  define  asset  motion,  signa¬ 
ture  noise  into  the  environment,  sensors  appropriate  to  the  simulation,  control  models  if  decision-making 
capabilities  are  required,  and  damage  models  to  assess  weapon  effects.  These  models  are  illustrated  with  a 
notional  communications  flow  in  Figure  3. 

Weapons  in  RMSSEA,  like  assets,  are  associated  with  meta  information  describing  the  basic  physical 
description,  and  relevant  models  implementing  aspects  of  the  device  significant  to  the  simulation.  A  wea¬ 
pon  includes  an  internal  publish/subscribe  board  where  models  within  the  asset  communicate.  Flistorically 
in  TMSS,  weapon  models  included  only  sensors  and  logic.  In  RMSSEA,  weapons  include  the  full  range 
of  model  functions,  allowing,  for  example,  motion  models  to  be  attached  to  moored  mines  for  motion  in 
the  water  column,  or  to  mines  with  a  mobile  warhead  allowing  the  system  to  model  rising  mines  and  en¬ 
capsulated  torpedo  devices. 

3.2  Environments 

Environments  describe  the  entire  encounter  space,  implement  communications  between  entities  through 
the  global  publish/subscribe  board,  provide  for  propagation  of  noise  from  one  entity  to  another,  and  pro¬ 
vide  appropriate  background  noise  where  applicable.  All  connections  through  and  within  the  environment 
are  implemented  using  the  publish/subscribe  method. 

Normal  simulation  engagement  execution  implements  an  initialization  step  followed  by  an  iterative 
nominally-circular  data  flow  until  the  simulation  engagement  completes.  In  the  initialization  stage,  all 
models  register  events  they  will  publish,  and  then  subscribe  to  events  they  consume.  Working  backwards 
from  the  weapon  logic  model,  the  weapon  logic  model  will  internally  subscribe  to  the  output  of  one  or 
more  associated  sensor  models.  The  sensor  model  will  subscribe  externally  to  the  influence  output  of  the 
environment  at  the  location  of  the  sensor.  The  environment  will  calculate  the  background  noise  for  that 
influence  at  that  location  (assuming  a  background  model  provides  this  data)  and  the  influence  model  will 
sum  that  background  with  the  outputs  of  propagation  models  valid  for  that  influence  type.  Each  propaga¬ 
tion  model  will  subscribe  to  each  asset’s  published  compatible  signature,  and  calculate  the  propagated 
signature  result  for  the  asset  at  its  location  relative  to  the  weapon  sensor  at  its  location.  If  the  weapon  log¬ 
ic  makes  a  firing  decision,  the  detonation  event  will  be  published  to  the  environment  where  nearby  assets 
can  be  informed  and  apply  that  detonation  event  to  their  internal  damage  models.  This  cycle  continues  un¬ 
til  some  condition  causes  the  simulation  engagement  to  complete,  and  the  simulation  continues  to  the  next 
defined  engagement. 

3.3  Analysis 

All  simulation  results  are  stored  within  the  system  SQL  database.  This  provides  a  single  consistent  inter¬ 
face  to  all  simulation  results,  for  all  engagements  simulated  for  a  given  simulation  study.  Data  stored  in 
the  database  can  be  accessed  either  for  individual  or  statistical  results,  depending  on  the  type  of  data  rec¬ 
orded  and  the  needs  of  the  analyst.  For  individual  results,  the  analyst  may  require  a  plot  of  the  propagated 
signature  seen  by  a  mine  sensor  time-correlated  with  the  sensor  response  and  logic  decisions  of  the  mine. 
This  could  support  better  understanding  of  the  firing  chain  of  the  weapon,  and  the  precise  signature  cha¬ 
racteristics  that  satisfied  the  weapon  firing  decision.  For  statistical  results,  the  analyst  may  want  an  output 
similar  to  Figure  1.  This  can  illustrate  multiple  effects  depending  on  needs,  including  the  effects  of  in¬ 
creasing  speed  on  susceptibility,  the  safe  operating  depth  of  a  platform  in  a  given  signature  condition,  and 
the  difference  in  ranges  of  satisfied  influences  for  multi-sensor  weapons. 
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Figure  3:  Entity  Diagram 


4  SYSTEM  USE 

RMSSEA  defines  a  simulation  as  a  hierarchical  structure.  A  top-level  RMSSEA  simulation  is  a  Study, 
which  primarily  exists  as  a  container  for  Tasks.  A  Task  in  RMSSEA  is  a  parameterized  definition  of  the 
encounters  of  one  or  more  assets  with  one  or  more  weapons  in  a  single  environment.  By  supporting  mul¬ 
tiple  independent  values  for  parameters  of  models  within  a  single  task,  a  task  can  define  one  or  more  en¬ 
gagements  of  the  asset(s)  against  the  weapon(s)  in  the  environment.  Weapons,  assets,  and  environments 
can  be  fully  defined  and  stored  in  the  RMSSEA  database  for  usage  in  multiple  studies,  allowing  quick  de¬ 
finition  of  studies  with  standard  configurations  of  assets  or  weapons. 

4.1  Ship  Susceptibility  Studies 

A  common  historical  use  of  TMSS,  and  therefore  an  expected  use  of  RMSSEA,  is  in  the  area  of  ship  sus¬ 
ceptibility.  For  this  use,  an  asset  is  defined,  possibly  in  multiple  configurations,  for  the  purpose  of  deter¬ 
mining  the  total  encounter  space  in  which  a  threat  weapon  may  be  able  to  detect  and  come  to  a  firing  de¬ 
cision  against  that  asset.  Using  the  RMSSEA  database  of  defined  threats,  an  analyst  must  create  only  the 
defined  asset  under  investigation.  The  RMSSEA  study  can  use  the  database  of  pre-defined  environments 
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and  weapons,  ensuring  that  these  are  in  standard  and  approved  configurations.  In  this  way,  a  study  can  be 
defined  that  completely  simulates  combinations  of  one-on-one  engagements  of  a  ship  in  multiple  configu¬ 
rations  versus  multiple  weapons  with  multiple  settings,  in  a  set  of  defined  environments  representing 
areas  of  interest.  This  study  could  be  used  for  any  of  several  uses  briefly  mentioned  in  the  Introduction  of 
this  paper,  including  operational  surface  ship  susceptibility  and  silencing  system  tradeoff  studies. 

4.2  Sweep  Effectiveness  Studies 

Alternately,  a  study  could  be  created  which  focuses  more  on  the  behavior  of  operational  or  developmental 
sweep  systems.  A  simplified  study  of  one-on-one  simulations  could  be  used  to  determine  operational 
sweep  effectiveness  characteristics  against  specific  threats,  used  as  inputs  in  standard  Navy  planning 
tools.  A  more  complex  study  could  simulate  a  complete  MCM  operation,  using  a  selection  of  Navy  sweep 
assets  in  a  defined  minefield  of  threat  weapons.  Such  a  simulation  could  support  analysis  of  alternatives 
to  standard  operational  guidelines  and  development  of  experimental  tactics. 

5  CONCLUSION 

Though  TMSS  has  been  utilized  for  many  years  to  provide  analysis  support  in  the  naval  mine  warfare 
community,  a  number  of  limitations  and  shortcomings  have  been  seen  over  the  years  that  the  current  im¬ 
plementation  is  not  readily  capable  of  overcoming.  A  redesign  of  the  basic  simulation  framework  is  re¬ 
quired  to  overcome  these  limitations  and  prepare  for  the  future  of  simulation.  That  design  and  implemen¬ 
tation  is  happening  under  RMSSEA.  The  RMSSEA  design  provides  the  full  capabilities  of  TMSS  but 
with  far  better  usability  and  maintainability.  RMSSEA  will  be  more  flexible  and  able  to  handle  the  simu¬ 
lation  needs  not  only  covered  by  the  current  TMSS  implementation  but  well  beyond.  This  paper  has  out¬ 
lined  the  design  of  RMSSEA  and  how  it  will  overcome  many  of  TMSS’s  current  limitations,  as  well  as 
describe  the  capabilities  and  usage  of  RMSSEA. 
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